The evolved packet core (EPC) reference model includes a variety of devices, such as mobility management entities (MMEs). A MME is a device that hosts the following functions: non-access stratum (NAS) signaling; NAS signaling security; access server (AS) security control; inter-core network (CN) signaling for mobility between Third Generation Partnership Project (3GPP) access networks; idle mode user equipment (UE) reachability (including control and execution of paging retransmission); tracking area list management (for UEs in idle and active modes); public data network (PDN) gateway (GW) and serving GW selection; MME selection for handovers with MME change; serving general packet radio service (GPRS) support node (SGSN) selection for handovers to 3GPP access networks; roaming; authentication; bearer management functions (e.g., dedicated bearer establishment); support for earthquake and tsunami warning system (ETWS) message transmission; etc.
The MME pool architecture (e.g., defined by the 3GPP) enables radio network elements (e.g., eNodeBs) to decouple from interfacing with a single MME, and permits the radio network elements to access multiple MMEs grouped in a structure known as a “pool.” MMEs communicate with each other via S10 interfaces, regardless of whether the MMEs are part of the same pool, different pools, or operate in isolation.
Under current 3GPP standards, MME load balancing achieves load-balanced MMEs with respect to the MMEs' traffic handling capacity within a MME pool (e.g., during system operation). The load balancing is achieved by distributing UEs (e.g., newly entering the MME pool) to different MMEs in the MME pool. With additional intervention (e.g., manual configuration by an operator), MME load balancing may achieve equally loaded MMEs (e.g., within the MME pool) after introduction of a new MME to the network and/or after removal of a MME from the network.
Support for MME load balancing is achieved by providing a relative MME capacity parameter (e.g., in a S1 protocol interface setup procedure) to all eNodeBs (eNBs) served by MMEs of a MME pool (e.g., per MME). In order to support the introduction and/or removal of MMEs, a MME-initiated S1 interface setup update procedure may be used by an operator to indicate changes in the relative MME capacity. The indicated relative MME capacity directs, in the eNBs, the assignment of UEs newly entering the MME pool.
An overload signaling procedure (also part of the S1 protocol) indicates to the eNBs that a serving MME is overloaded (e.g., unable to receive new UE assignments), and indicates to the eNBs that the serving MME has returned to a normal operation mode once the overload condition has been cleared. S1 interface messages are defined in the S1 protocol, as set forth in 3GPP TS 23.401. Details of what the MME could request from the eNBs while operating in an overload situation are also included in 3GPP TS 23.401. 3GPP TS 23.401 further specifies certain conditions and recommendations for how to offload subscribers (e.g., UEs) from an MME, when the MME is undergoing maintenance. This operation is known as load re-balancing between MMEs.
Load balancing (also known as the “m balls into n bins problem”) has been comprehensively studied for many years in mathematics and computer science. Both centralized and distributed solutions have been proposed. The majority of theoretical studies involve some level of knowledge about the load of the bins, before deciding in which bin to place a particular ball. A significant (e.g., exponential) decrease between differences in the number of balls between the bins could be achieved if the load of two randomly sampled bins is known and the ball is thrown into the bin with the least load.
Generic communication protocols that support load balancing have also been proposed. Centralized versions of such communication protocols require the existence of a node (or set of nodes) that has perfect knowledge of a load on a system. Such a node is commonly referred to as an oracle. In one exemplary system, a centralized, oracle-based scheme for pool server management is used. Processing resources register themselves with the oracle and report load information to the oracle via a protocol.
A proposed distributed solution permits nodes to build approximate knowledge of an overall system load by exchanging information between small sets of nodes using a gossip protocol. Each node computes its load, disseminates its load using the gossip protocol, and uses multicast for urgent dissemination of its load (e.g., when the load changes quickly).
A proposed node-based solution achieves a balanced system by permitting processing nodes to directly offload jobs between themselves. The strategy is based on random matching nodes and having the nodes equalize the load (e.g., measured in jobs that are greater than a particular age). The system handles both static load (e.g., where no new jobs enter the system after a particular time) and dynamic load (e.g., where new jobs enter and some existing jobs leave the system at any time).
The current solutions for load balancing have several disadvantages. For example, pure random assignment of UEs (e.g., by eNBs) to MMEs within a MME pool creates an imbalance between the most occupied and least occupied MME. Furthermore, the MME relative capacity (set forth in 3GPP TS 23.401), which is used when implementing a weighted round-robin assignment of UEs (e.g., by eNBs) to MMEs, is expressed as one value per MME. It remains a manufacturer-specific feature to determine if the MME relative capacity is to be made proportional only with a number of licenses supported by the MME or if the signaling capacity of the MME is to be considered as well. If the signaling capacity of the MME is considered, a single dimensional value may be insufficient to create an unambiguous representation of the MME relative capacity.
The mechanism described in 3GPP TS 23.401 also creates temporary interruptions of UE services while a re-balancing operation is taking place. Furthermore, triggering re-balancing operations during MME maintenance and upgrade operations requires significant manual intervention. If failures occur that temporarily reduce the MME capacity, current solutions require manual intervention for determining a new set of load weights and for disseminating the new set of load weights. For inter-pool mobility (e.g., during S1 handovers or when an idle UE crosses a boundary between areas served by different MME pools) current solutions fail to take into account information related to a load on a target MME pool in order to optimize user placement within a new MME pool.
The overload signaling procedure permits the MME to tell eNBs to no longer send new subscribers (e.g., UEs), but does not specify what to do to solve an overload situation. Presumably, solving an overload situation in this procedure would involve manual intervention where an operator manually offloads some served UEs to other MMEs in the pool.
The centralized solutions require load information from a MME pool to be propagated to a centralized oracle that receives requests from eNBs about which MME to assign a particular UE. Such centralized solutions add delay (e.g., due to the communication between the eNBs and the oracle) and increase scalability requirements for the oracle.
The distributed solution requires a MME pool to provide load information to all served eNBs, in addition to making the load information available to members of other MME pools. Further, given a maximum number of devices in a MME pool (e.g., sixteen, thirty-two, or sixty-four), a gossip-based strategy for load information dissemination fails to address scalability issues.
The node-based solution, as applied to a MME pool, may enable a system to be maintained in a balanced state by continuously moving UEs between MMEs in the pool. However, the one-to-one matching between processing nodes proposed by the solution would not permit automatic handling of maintenance situations (e.g., when a MME needs to offload its entire load) without creating further imbalances in the MME pool.